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1,  Miro  Productivity  Measures 

Refereed  papers  submitted  but  not  yet  published:  1 
Refereed  papers  published:  2 
Unrefereed  reports  and  articles:  3 

Books  or  parts  thereof  submitted  but  not  yet  published:  1 

Books  or  parts  thereof  published:  0 

Patents  filed  but  not  yet  granted;  0 

Patents  granted:  0 

Invited  presentations:  0 

Honors  received  (fellowships.  iechni.  »l  society  appointments,  conference  committee  role,  editorship,  etc):  0 
Prizes  or  awards  received:  0 
Promotions  obtained:  0 

Graduate  students  supported  >=  25%  of  full  time:  I 


Post-docs  supported  >=  25%  of  full  time:  0 
Minorities  supported:  0 
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2.  Mii’6  Summary  of  Teclinical  Progress 

The  Miro  group  is  designing  and  implementing  a  package  of  two  visual  languages  for  computer  security 
specifications.  The  instance  language  describes  .static  filesystem  configurations;  who  are  the  users,  and  what 
files  can  they  access  at  this  moment  in  time?  The  consiratnt  language  defines  sets  of  legal  instance  pictures; 
what  configurations  are  allowed?  In  t  he  past  year,  we  have  completed  the  design  of  these  languages,  and 
have  begun  to  implement  the  tools  necessary  to  make  them  part  of  a  working  software  system. 
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3.  Mir6  Detailed  Summary  of  Teclmical  Results 

The  Miro  group  is  designing  and  implementing  a  package  of  two  visual  languages  for  computer  security 
specifications.  The  inalanct  language  describes  .static  filesystem  configurations;  who  are  the  users,  and 
what  files  can  they  access  at  this  moment  in  time?  The  constraint  language  defines  sets  of  legal  instance 
pictures;  what  configurations  are  allowed?  By  October  1988,  work  on  the  instance  language  was  essentially 
complete:  a  formal  description  of  its  semantics  was  presented  at  the  Visual  Language  workshop  that  month 
in  [1].  The  constraint  language  then  developed  over  the  course  of  the  1988*1989  academic  year.  The  rest  of 
this  summary  presents  highlights  of  the  constraint  language.  A  complete  description  can  be  found  in  [2]. 


3.1.  Background 

Miro  is  a  visual, language  for  specifying  security  configurations.  By  “visual  language.”  we  mean  a  language 
whose  entities  are  graphical,  such  as  boxes  and  arrows.  By  “specifying,"  we  mean  stating  independently  of 
any  implementation  the  required  and/or  desired  properties  of  a  system.  Finally,  by  “security,”  we  mean 
security  for  operating  systems:  ensuring  that  files  are  protected  from  unauthorized  access  and  granting 
privileges  to  perhaps  some  users,  but  not  others. 

Our  work  differs  from  other  work  in  visual  languages  in  three  important  ways:  First,  unlike  many 
languages  based  on  diagrams  where  boxes  and  lines  may  fail  to  have  a  precise  meaning,  or  worse,  have 
multiple  interpretations,  we  are  careful  to  provide  a  completely  formal  semantics  for  our  visual  language. 
Second,  in  contrast  to  visual  programming  language.s.  we  are  interested  in  specifications,  not  executable 
programs.  Third,  we  do  not  use  visualization  just  for  the  sake  of  drawing  pretty  pictures:  instead,  we 
address  a  domain,  security,  that  lends  itself  naturally  to  a  two-dimensional  representation. 

Security  lends  itself  naturally  to  visualization  becauw’  the  domains  of  interest  are  best  expressed  in  terms 
of  relations  on  .sets,  easily  depicted  a.s  Venn  diagram.s.  and  the  connections  among  objects  in  these  domains 
are  best  expressed  as  relations  (e.g.,  access  rights),  easily  depicted  as  edges  in  a  graph  (where  the  nodes  are 
Venn  diagrams).  The  underlying  model  is  a  two-dimensional  access  rights  matrix,  but  the  compact  visual 
notation  presents  the  same  information  in  a  more  intuitive  manner.  The  Miro  instance  and  constraint 
languages  extend  Ilarel’s  work  on  higraphs.  an  elegant  formalism  that  shows  relations  on  Venn  diagrams. 

Figure  1  shows  a  Miro  security  specification  that  reflects  some  aspects  of  the  Unix  file  protection  scheme. 
The  outermost  left-hand  box  depicts  a  world.  World,  of  users,  two  groups.  Groupl,  and  Group2,  and  two 
users,  Alice  and  Bob,  The  containment  and  overlap  relationships  between  the  world,  groups,  and  users 
indicate  that  all  users  are  in  the  world,  and  that  some  users  are  members  of  more  than  one  group.  The 
right-hand  box  denotes  the  .set  of  files  in  .Alice’s  mail  directory.  The  arrows  indicate  that  Alice,  and  no 
other  user,  has  read  access  to  her  imil  files.  She  is  granted  read  permission  because  the  direct  positive 
arrow  from  Alice  overrides  (i.e,.  is  more  tightly  nested  than)  the  negative  arrow  from  World, 


Figure  1:  A  Sample  Miro  Picture 

3.2.  Constraint  Language 

Miro  is  expressive  enough  to  specify  security  configurations  for  any  operating  system.  However,  the  kinds 
of  pictures  users  can  draw  will  vary  depending  on  the  kind  of  system  they  are  specifying.  In  particular,  the 
system  architecture  will  impose  constraints  on  what  should  be  considered  a  “legal”  (realizable  and 
acceptable)  picture  for  that  system.  For  example,  a  legal  picture  for  Multics  may  be  illegal  for  Unix 

Constraints  themselves  are  specified  by  pictures  drawn  in  a  visual  language  similar  to  the  Miro  picture 
language  outlined  above.  We  make  the  distinction,  therefore,  between  Miro  instance  pictures  and  Miro 
constraint  pictures.  Each  constraint  specifies  a  “pattern,”  which  is  a  template  for  many  different  instance 
pictures.  Instance  pictures  may  match  the  pattern  given  by  a  constraint  picture. 

Constraints  are  typically  statements  in  which  the  occurrence  of  some  situation  will  imply  that  some  further 
condition  should  hold.  Therefore,  constraints  are  divided  into  two  parts:  the  antecedent  (or  trigger)  and 
the  consequent  (or  requirement).  For  example,  we  may  wish  to  specify  the  constraint  that  any  time  a  user 
has  write  access  to  a  file,  he  should  also  have  read  access  to  it.  In  this  case,  the  existence  of  write  privilege 
is  the  “trigger”  of  the  read  privilege  “requirement.”  Both  parts  are  expressed  together  in  a  single 
constraint:  the  trigger  is  drawn  with  thick  lines,  the  requirement  with  thin  line.  Following  we  two 
constraint  picture  examples: 

1.  Whenever  a  User  has  write  access  to  a  File,  he  should  also  have  read  access  to  that  File. 


2.  Every  Group  must  be  directly  contained  in  at  lea.st  one  World,  and  a  Group  can  only  be  contained  in  a 
World. 


«-■  -  — . 

type  -  World 

!  ( type  -  World ) 

_ I _ 

T 

X 

[type  m  Group] 

[type  -  Group] 
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The  features  of  the  constraint  latijjuage  are  detailed  in  [2];  the  following  summarizes  the  constraint 
language  constructs; 


Syntax  Arrows;  These  match  against  individual  arrows  in  an  instance  picture. 

Semantics  Arrows:  These  match  relations  in  the  two'dimensional  access  matrix. 

Containment  Arrows:  Containment  arrows  must  join  two  boxes.  They  are  matched  when  one  instance 
box  is  dirtcUy  contained  withiit  the  other. 


Starred  Containment:  Matches  when  one  box  is  contained  within  the  other  ai  any  level  (i.e.,  there  may 
be  boxes  surrounding  the  smaller,  yet  still  contained  within  the  larger). 

Negated  Arrows:  Any  of  the  arrows  may  be  negated.  For  syntax  arrows,  it  means  there  is  a  negative 
arrow  joining  two  boxes:  for  semantic  arrows,  it  means  the  relation  is  negative;  for  containment 
arrows,  it  means  one  box  is  not  contained  in  the  other. 

Box  Patterns:  Each  constraint  box  may  have  a  predicate  to  restrict  the  kinds  of  instance  boxes  it 
matches.  For  example,  type  s  User  &  name  =  "jones"  would  only  match  an  instance  User  (as 
opposed  to  File)  box  with  the  name  Jones. 

Thick  and  Thin:  For  all  parts  of  the  instance  picture  matching  the  thick  parts,  there  must  exist  instance 
subpict'ures  matching  the  thin  parts. 


Numeric  Constraints:  A  range  limit  can  be  given  on  the  number  of  subpictures  that  match  the  thick 
part  of  the  constraint. 


3.3.  Implementation 

We  are  designing  a  set  of  tools  that  will  allow  us  to  exploit  Mir6’s  capabilities.  Our  front-end  tools  are 
operating  system  independent,  and  use  an  inter:nedinte  file  format  to  represent  instance  pictures  and 
constraints;  the  back-end  tools  use  the  intermediate  file  format  to  interface  with  actual  operating  systems. 

The  front-end  tools  include  the  Mirfi  graphical  editor,  which  allows  users  to  view  and  modify  instance 
pictures  and  constraints.  The  editor  runs  under  the  X  Window  system  and  is  built  on  top  of  the  Garnet 
system,  developed  at  Carnegie  Mellon,  The  editor  provides  simple  syntactic  checks,  and  translates  pictures 
and  constraints  into  our  intermediate  Rle  format.  It  also  provides  the  ability  to  ‘‘zoom”  out  and  in  to  allow 
the  user  to  abstract  away  or  focus  in  on  details  of  a  picture,  and  to  “highlight”  the  sub-pictures  of  interest, 
The  Mir6  printing  package  takes  the  intermediate  file  format  and  produces  a  PostScript  file  of  the  Mir6 


0 


plcturt.  Th«  fdir6  tiatie  iinfat^iei  checker  chtck$  a  picturt  for  ambiguity  or  violations  of  constraints,  and 
reports  any  e^rs, 

The  back-end  tools  , include  the  Mird  file  tyiiem  checker,  which  probes  the  flie  system  to  check  whether  a 
given  hie  system’s  protection  conforms  with  its  instance  language  description,  A  different  hie  system 
checker  is  needed  for  each  operating  system  on  which  Mir6  will  be  used,  We  are  investigating  the  feasibility 
of  a  Mir 6  file  eyeiem  impeciion  tool  whicli  could  alter  ,an  instance  picture  to  correspond  to  the  actual  state 
of  the  hie  system.  The  hie  system  inspection  tool  raises  a  number  of  interesting  questions  in  the  area  of 
automated  production  of  attractive  graphs.  Of  the  tools  mentioned,  we  have  prototypes  of  the  graphical 
editor,  static  semantics  checker,  and  the  printing  package. 

In  conclusion,  the  Mir6  system  provides  a  convenient  visual  language  for  specifying  security  properties. 

Our  future  work  will  concentrate  on  applying  the  Mir6  languages  to  domains  other  than  security. 
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5,  Miro  Research  Transitions  and  DoD  Interactions 


Through  workshop  and  conference  presentations,  other  researchers  are  becoming  interested  in  our  work. 
Since  the  tools  are  still  in  the  development  phase,  however,  no  substantial  transitions  have  occurred. 
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6.  Miro  Software  and  Hardware  Prototypes 

We  have  entered  into  the  software  development  phase  of  our  research.  We  now  have  a  working  editor, 
printing  tool  and  ambiguity  checker.  These  are  all  prototype  versions,  however.  Over  the  next  year  we  will 
refine  these  tools,  and  hope  to  complete  several  others.  See  the  paper  Mtro  Tools  for  more  details  on  the 
status  of  our  software. 
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1  Productivity  Measures 

Refereed  papers  submitted  but  not  yet  published:  1 

Refereed  papers  published:  0 

Unrefereed  reports  and  articles:  2 

Books  or  parts  thereof  submitted  but  not  yet  published:  1 

Books  or  parts  thereof  published:  0 

Patents  filed  but  not  yet  granted:  0 

Patents  granted:  0 

Invited  presentations:  0 

Honors  received  (fellowships,  technical  society  appointments,  conference  committee 
role,  editorship,  etc):  0 
Prizes  or  awards  received:  0 
Promotions  obtained:  0 

Graduate  students  supported  >=  25%  of  full  time:  1 
Post-docs  supported  >=  25%  of  full  time:  0 
Minorities  supported:  0 
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2  Summary  of  Technical  Progress 

In  the  Fall  and  Winter,  we  completed  work  on  Avalon/C++,  a  fault-tolerant,  dis¬ 
tributed  programming  language.  In  the  spring,  we  mounted  a  design  effort  towards 
implementing  Avalon/Common  Lisp,  an  extension  to  Common  Lisp  with  support  for 
reliable,  distributed  computing. 

Over  the  summer,  the  Avalon/Common  Lisp  group  designed  and  implemented  a 
prototype  version  of  our  system  using  CMU  Common  Lisp,  Mach  (for  remote  data 
transmission),  and  Camelot  (for  fault  tolerance  and  primary  recoverability).  Future 
work  will  entail  refining  our  ideas  concerning  system  semantics,  and  modifying  the 
implementation  to  conform  to  them. 
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3  Detailed  Summary  of  Technical  Results 

Project  Goals 

A  distributed  system  consists  of  multiple  computers  (called  sites)  that  communicate 
through  a  network.  Distributed  systems  are  typically  subject  to  site  crashes  and 
communication  link  failures.  A  crash  renders  a  site’s  data  temporarily  or  permanently 
inaccessible,  while  a  communication  link  failure  causes  messages  to  be  lost  A  failure 
is  detected  when  a  site  that  has  sent  a  message  fails  to  receive  a  response  after  a 
certain  duration.  The  absence  of  a  response  may  indicate  that  the  original  message 
was  lost,  that  the  reply  was  lost,  that  the  recipient  has  crashed,  or  simply  that  the 
recipient  is  slow  to  respond. 

The  primary  goal  of  the  Avalon  Project  is  to  create  a  set  of  linguistic  constructs 
designed  to  give  programmers  explicit  control  over  transaction-based  processing  of 
atomic  objects  for  fault-tolerant  applications.  These  constructs  have  been  imple¬ 
mented  as  extensions  to  C-m-  and  Common  Lisp.  The  constructs  include  new  encap¬ 
sulation  and  abstraction  mechanisms,  as  well  as  support  for  concurrency  and  recovery. 
The  decision  to  extend  an  existing  language  rather  than  to  invent  a  new  one  was  based 
on  pragmatic  considerations.  We  felt  wc  could  focus  more  effectively  on  the  new 
and  interesting  issues  of  reliability  and  concurrency  if  wc  did  not  have  to  redesign  or 
reimplement  basic  language  features,  and  we  felt  that  building  on  top  of  a  widely- 
used  and  widcly-available  language  would  facilitate  the  use  of  Avalon  outside  our 
own  research  group. 

Past  Accomplishments 

Last  fall  and  winter,  we  completed  our  efforts  on  Avalon/C+-t-,  an  extension  to  C-m-.[8] 
My  time  was  spent  debugging  the  data  uansmission  package  (which  I  designed  and 
built  the  previous  summer),  and  implementing  an  example  of  a  highly-available  and 
recoverable  data  type  in  our  Avalon/C++  system.  The  data  type,  a  simple  counter, 
grounded  at  zero,  illustrates  a  number  of  the  unique  features  of  Avalon/C-H-. 
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A  defied  presentation  of  the  language  and  its  features  can  be  found  in  [1]  and 
in  the  part  of  [3]  devoted  to  discussion  of  the  Avalon/C++  project 

By  late  winter,  our  research  efforts  in  Avalon/C++  gave  way  to  the  initial  de¬ 
sign  of  Avalon/Common  Lisp,  i.e.  a  Common  Lispt?]  with  support  for  distribution, 
concurrency,  reliability  and  fault-tolerance.  While  the  goals  were  similar  to  those  of 
the  Avalon/C +-t-  effort,  our  design  resulted  in  a  different  computation  model.  These 
differences  were  the  result  of  influence  from  a  number  of  directions,  both  technical 
and  practical. 

One  of  the  initial  design  goals  of  the  Avalon  Project  was  to  extend  existing 
languages,  rather  than  invent  new  ones.  In  the  process  of  such  an  extension,  it  is 
important  to  introduce  as  few  new  features  as  possible,  and  design  those  features 
to  combine  well  with  the  base  language’s  idioms  and  model  of  computation.  In 
Avalon/C+-i-,  we  chose  an  object-oriented  design,  consistent  with  the  C-h-  model. 
In  Avalon/Common  Lisp,  we  strove  to  extend  the  language  in  a  similarly  consistent 
manner. 

The  most  significant  enhancement  we  made  to  Common  Lisp  was  the  addition  of 
a  new  first-class  data  type,  the  evaluator.  An  evaluator  represents  an  additional,  non¬ 
local,  Common  Lisp  evaluator,  on  which  the  user  can  evaluate  expressions,  install 
procedures,  and  modify  accessible  data.  Evaluators  are  used  via  two  new  macros, 
remote  and  local,  which  direct  the  thread  of  computation  to  a  different  evaluator. 

Avalon/Common  Lisp  is  built  on  top  of  three  locally-developed  systems,  CMU 
Common  Lisp,  Mach,  and  Camelot,  and  runs  on  IBM-PC/RTs.  CMU  Common  Lisp 
is  one  of  the  first  implementations  of  Common  Lisp,  and  was  chosen  over  other 
Common  Lisp  implementations  for  two  reasons.  Firstly,  it  is  the  only  available 
Common  Lisp  that  runs  on  the  computers  the  Avalon  Croup  had  already  available. 
We  also  favored  the  presence  of  the  support  and  maintenance  the  locally-managed 
system  provides. 

Mach[l],  a  Unix-like  operating  system  with  support  for  distributed  computation, 
is  used  to  provide  communication  among  the  various  Avalon  processes,  and  to  support 
process-level  concurrency.  Camelot[5,3],  a  machine-independent,  high-performance, 
disu-ibuted  uansaction  facility,  is  used  to  support  the  fault-tolerance  and  reliability 
we  desire. 

Over  the  summer,  we  designed  and  built  a  prototype  version  of  Avalon/Common 
Lisp.  The  implementation  supports  most  of  the  features  we  had  envisioned  for  the 
system,  with  the  exception  of  some  of  the  more  expensive  features.  Please  refer  to 
the  enclosed  Carnegie  Mellon  Tcchn.cal  Report  [2]  for  details. 

My  own  work  has  focused  on  the  design  of  the  remote  evaluation  model  for 
Avalon/Common  Lisp,  and  on  the  interface  between  the  Camelot  recoverable  vinual 
memory  system  and  the  Common  Lisp  ilata-type  system. 

The  remote  evaluation  model  provides  an  interesting  model  of  computation  for 
distributed  computing.  Instead  of  remote  servers  and  remote  procedure  calls,  the  dis¬ 
tribution  of  the  computation  is  generalized  to  a  set  of  remotely  situated  Common  Lisp 
evaluators,  which  communicate  via  “remote  evaluator”  calls.  While  not  significantly 
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more  computationally  expensive  from  the  point  of  view  of  the  implementation,  this 
model  provides  a  richer  environment  for  the  programmer.  (See  [2]  for  examples.) 

The  remote  evaluation  model  was  inspired  by  Stamos’  PhD  work  [6]  and  by  my 
experiences  with  Avalon/C++  in  previous  years.  (See  last  year’s  Fiscal  Report  for 
details  of  my  work  with  Avalon/C-H- .) 

The  design  and  implementation  of  the  interface  between  the  Camelot  recoverable 
virtual  memory  system  and  Common  Lisp  mostly  involved  the  integration  of  the 
Cameloi/Common  Lisp  interface  provided  to  us  by  the  Camelot  Group,  and  the 
demands  of  the  standard  Common  Lisp  data  types.  Camelot,  having  been  written 
in  C,  understand  only  basic  C  data  types.  Any  useful  Lisp  interface,  however,  must 
understand  the  more  complex  data  types  present  there  (lists,  vectors,  structure,  etc.). 
I  expended  much  effort  implementing  most  of  the  Common  Lisp  data  types  on  top 
of  the  primitive  data  types  provided  by  the  Camelot  interface. 

Future  Goals 

My  research  plans  for  the  next  year  are  twofold.  First,  during  the  Fall,  I  plan  to 
augment  the  existing  Avalon/Common  Lisp  prototype  to  support  some  of  the  more 
interesting  features  of  my  initial  remote  evaluation  design.  In  our  effort  to  get  the 
prototype  running  by  the  end  of  the  summer,  we  passed  over  some  of  the  features 
that  required  additional  research  and  extensive  implementation  efforts,  mainly  sharing 
of  data  among  transmitted  objects,  and  propogation  of  side-effects  across  evaluator 
boundaries. 

In  the  new  year,  we  plan  to  start  work  on  the  next  generation  of  Avalon/Common 
Lisp.  At  this  time,  it  appears  as  if  we  will  choose  a  different  Lisp  dialect  (probably 
Scheme)  as  our  base  language.  While  Common  Lisp  provided  a  fertile  testbed  for 
our  work,  a  simpler,  cleaner  language  will  allow  us  to  better  explore  the  more  formal 
aspects  of  our  research. 

On  another  front,  we  have  begun  di.scussing  our  ideas  with  the  ML  language[4] 
community  here  at  SCS,  in  an  effort  to  understand  what  a  distributed  ML  might  look 
like. 

I  personally  plan  to  explore  in  detail  the  idea  of  extending  our  ideas  about  dis¬ 
tributed  computation  models  with  the  ML  researchers.  During  our  talks,  we  have 
discovered  that  we  can  learn  about  our  research  by  trying  to  cast  it  into  a  framework 
that  other  language  researchers  can  understand. 
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4  Publications,  Presentations  and  Reports 

Below  are  the  list  of  Avalon  publications  I  have  been  involved  with  during  the  past 

year 

References 

[1]  Jeannette  Wing,  ct  al.  The  Avalon/C++  Programming  Language  (Version  0). 
Technical  Report  CMU-CS-88-209,  Carnegie  Mellon  University,  December  1988. 

[2]  S.M.  Clamen,  L.D.  Leibengood,  S.M.  Nettles,  and  J.M.  Wing.  Reliable  Dis- 
iribuied  Computing  with  Avalon/Common  Lisp.  Technical  Report  CMU-CS-89- 
186,  Carnegie  Mellon  University,  September  1989.  Submitted  to  1990  IEEE 
Computer  Society  International  Conference;  an  extended  abstract  appears  as  "An 
overview  of  Avalon/Common  Lisp,”  in  the  Proceedings  of  the  Third  Worieshop 
on  Large  Grained  Parallel  Programming  (Pittsburgh,  PA,  October  10-11,  1989). 

[3]  Jeannette  Wing,  et  al.  The  Avalon  language.  In  Jeffrey  L.  Eppinger,  Lily 
B.Mummen,  and  Alfred  Z.  Spector,  editors.  Guide  to  the  Camelot  Distributed 
Transaction  Facility  including  the  Avalon  Language,  Prentice-Hall,  Englewood 
Cliffs,  New  Jersey,  1989. 


7 


Nico  Habennann 
Carnegie  Mellon  University 
School  of  Computer  Science 
(412)  268  -  2592 
anh@cs.cmu.edu 

ONR  Funding  for  Mir6  and  Avalon 
Student  Reporting  -  Stewart  Michael  Clamen 
NOOOM  -  88  -  K  -  0641 
1  Oct  88  -  30  Sep  89 


5  Research  Transitions  and  DoD  Interactions 

A  number  of  researchers,  in  both  academia  and  industry,  have  expressed  an  interest 
in  our  Avalon/C-H-  work.  Commercial  sit«  include  Microsoft,  Texas  Instruments, 
Hewlett  Packard,  and  NCR.  Academic  sites  include  Boston  Univeristy,  University  of 
Massachusetts  -  Amherst,  Concordia  University  (Montreal),  and  University  of  New 
South  Wales  (Australia).  (A  more  detailed  list  is  available  upon  request) 

Our  research  with  Common  Lisp  has  not  had  much  publicity  as  yet,  so  not  much 
interaction  on  that  topic  has  yet  occured.  Our  upcoming  publication  should  remedy 
that  situation. 
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6  Software  and  Hardware  Prototypes 

Avalon/C-t"*-  is  stable  and  available  for  distribution.  Avalon/Common  Lisp  is  not 
quite  stable,  but  efforts  within  the  next  few  months  will  improve  its  condition.  Plans 
over  the  next  year  are  to  redesign  and  reimplement  the  AvalonyCommon  Lisp  on  a 
different  testbed  and  to  design  and  build  a  new  system  to  achieve  Ca2'i.elot’s  without 
the  unnecessary  overhead  Camelot  currently  possesses. 


